One feature of syslog-ng PE is support for wildcard file sources, meaning you can give it a wildcard, like /var/log/apache/*.log, and it will automatically notice new files being created or old ones disappearing. This is a very useful feature which has been missing from the open source edition, and one that is being worked on, but is far from complete, and will not make it into syslog-ng 3.5. However, at least on GNU/Linux, there is a way to implement something similar, although in a fairly crude manner. Yet, it works surprisingly well in most cases. You only need to abuse a few things...The trick itself is pretty easy, and is based on the same underlying kernel feature that syslog-ng PE uses under the hood: inotify(7). What we will do, is use incron to monitor a directory, and create syslog-ng config file snippets whenever a file creation event occurs. We also set up syslog-ng to include these snippets, and reload the configuration after each event received. This way, we immediately notice newly created logfiles without the need to poll the directory, and with config snippets created on the fly, we do not modify the main syslog-ng configuration file, either.To do this, we first need to create an appropriate syslog-ng configuration:

@version: 3.5
destination d_all_logs  
  file("/var/log/all.log");
 ;
include "/etc/syslog-ng/conf.d/notify-*.conf";

The config itself is a dummy: it has no sources, no logpaths, just a destination, which we will use in the snippets. Next, we create the script that will create these for us! It takes a single command-line argument: the filename of the newly created logfile. This creates the config snippet with a unique filename and source name, adds a new logpath that binds it to the d_all_logs destination defined in the main configuration file, and reloads the configuration afterwards.Now, all we need is to tell incron to call this script. Assuming we saved it as /usr/local/sbin/syslog-ng-wildcard-notify, this is how the incrontab entry would look like:

/var/log/remote.d/*.log  IN_CREATE,IN_MOVED_TO /usr/local/sbin/syslog-ng-wildcard-notify $@/$#

And that's about it! Now whenever a new file gets dropped into the directory, syslog-ng will get notified. There is a downside, however: when a file gets deleted, the configuration is not removed. That part is not so simple, though: we want syslog-ng to finish reading the file before reloading the config, so that makes it a bit trickier. But if we don't care about that, we could just add an IN_DELETE event, and write another script that looks up which snippet is responsible for the file, delete it and reload. Doing that is left as an exercise for the reader!

The first alpha of syslog-ng 3.4 was released more than a year ago, and the first stable release earlier this year, development on syslog-ng 3.5 has been going on steadlily since then, with a lot of interesting features and changes pouring in. While the 3.5 release will not bring as many overwhelming changes as the previous two releases did, the sheer number of improvements is still substantial. Our focus was on smaller developments all over the place this time, instead of big sweeping changes. In this post, we will go over most of these features, with use-cases, examples and a few words about why they are so useful and awesome.Multi-line support, new destinations, new template functions, type hinting, unit suffixes, and other things. Read on, and be amazed!These are only bigger features, there has been a lot of small tweaking going on, and of course, all of the fixes that went into prior versions will also be in 3.5 too, and there's still a chance that something else may find its way in before the feature freeze.Multi-line supportOne of the major new features in the 3.5 release will be support for multi-line messages, a feature that has been available in syslog-ng PE for a good while, and which has been ported to and improved upon to the open source edition. Two variants of multi-line are supported, which will be detailed below. Both of them are available for the file() and pipe() sources only.Indented multi-lineThe easiest variant is indented multi-line, where each line can be followed by others, indented by whitespace, and the message continues until the first non-indented line. This is the format used by the Linux kernel too, from version 3.5, for /dev/log. This type of multi-line can be used as follows:

source s_multiline   file("/path/to/file" multi-line-mode(indented));  ;

Consider that /path/to/file has the following content:

First line
 Continuation 1;
 Continuation 2;
Second line

With the indented multi-line-mode() setting, this would turn into two log messages:

First line\n Continuation 1;\n Continuation 2;
Second line

Regexp-based multilineIf multi-line input is not based on indentation, one can use the regexp multi-line-mode() instead, which makes two new settings available: multi-line-prefix() and multi-line-garbage(). These can be used to define the start and the end of a log message: any string between a the beginning matching prefix and a matching garbage will be considered a single message. That is, the prefix will be included, the garbage will not be: it will be discarded.To illustrate:

source s_multiline  
 file("/path/to/file" multi-line-mode(regexp)
                      multi-line-prefix("^prefix")
                      multi-line-garbage(" garbage$"));
 ;

If the source contains these lines:

prefix message
continuing garbage

This will turn into the following log message:

prefix message\ncontinuing

New destinationsIt would be pretty hard to do a syslog-ng release without new destinations, and with 3.5, we will have three of them!STOMPWhile we had AMQP before, we now have a STOMP destination too, so we can stream logs to any STOMP server, with a few simple lines:

stomp(
 host("localhost")
 port(61613)
 destination("/topic/syslog")
 routing_key("")
 persistent(yes)
 ack(no)
 username("someone")
 password("something")
 body("This is the body! YAY! Here's a message: $MESSAGE!\n")
 value-pairs(scope(nv-pairs, syslog-proto, selected-macros))
)

Of course, none of these settings need to be set, you can just use the defaults, and it will just work!RiemannDid you know that syslog-ng is far more than a log collector and processor? No? You do now. When you have access to a lot of logs, and a tremendous amount of power in parsing them, you can use these tools for monitoring easily! And when we're talking monitoring, riemann is a great asset in our toolbox, and with the new destination, we can easily forward metrics to it:

riemann(
 server("localhost")
 port(5555)
 host("$HOST")
 service("$PROGRAM")
 description("$PROGRAM pids")
 metric(int("$PID"))
 ttl(300)
);

Of course, the above is a very silly example, it would make much more sense to extract data from a log message instead, but this will serve as an example.New template functions

$(upper-case TEXT...), $(lower-case TEXT...)

To turn some text into *upper-* or *lower-case*, these two template functions come in handy. They simply turn all their arguments into the respecitve case.

$(delimit DELIMITERS NEW-DELIMITER TEXT)

Sometimes one has a delimited string, where one wishes to replace the delimiters. This function does just that: give it a list of delimiters (you may need to quote it, if it contains whitespace), a replacement, and a text to replace delimiters in, and it does the rest. For example, to replace tabs and spaces with a vertical bar, one could write a template like this:

template("$(delimit \"\t \" \" \" $MESSAGE)\n")

$(env VARIABLE...)

Have you ever felt the need to check an environment variable from within syslog-ng? I did, and now I can.

Type hintingWhile syslog-ng supported sending log messages into various data stores and message queues for a while (SQL at first, MongoDB, JSON and AMQP later), even when those supported different types of data than strings, we could not do anything else. Until now. It is now possible - at places where it makes sense - to annotate templates with type hints, which the destination driver can optionally use. Type hinting is implemented for the mongodb() destination and the $(format-json) template function for now. When no type hint is specified, syslog-ng defaults to string.To add type hints, simply wrap the respective template with the hinted type, like this:

mongodb(
 value-pairs(pair("date", datetime("$UNIXDATE"))
             pair("pid", int64("$PID")))
);

Currently the following type hints exist: boolean (anything that begins with a t or 1 is true, anything that begins with f or 0 is false, everything else is an error), string, literal (same as string, but not quoted if it would be quoted otherwise), int32 (int is an alias for this), int64, and datetime. Only UNIX timestamps can be type-hinted to datetime, anything else will likely result in a casting error.It is also possible to control what happens when type casting fails: syslog-ng can drop the whole message, drop the property, or fall back to string. It can also do all of these silently:

options  
 typecast(on-error(silently-drop-property));
 ;

Using this feature with $(format-json) is very similary too:

$(format-json date=datetime("$UNIXDATE") pid=int64("$PID"))

With this feature in place, you can now store your non-string values with their proper types!Unit suffixesUnit suffixes make it considerably easier to set limits and describe numbers within the syslog-ng configuration. We no longer need to spell out sizes to the byte precious, it is now enough to write: log-fifo-size(200MiB). Now, syslog-ng will understand suffixes for kilo-, mega-, and giga-bytes, (K, M, G, respectively) either in base-10 or base-2 (with an extra i after the suffix). One can also omit the trailing b from the end.So, to set the log-fifo-size() to 2097152 bytes, one can simply use 2MiB. Or, to set it to 2000000, 2Mb. That's a whole lot easier, isn't it? No more counting zeros, no more silly typos in a ten-digit number, no more pain, but easily readable units!Miscellaneous featuresApart from the features above, there have been a lot of other changes and improvements in the code base:

• We now have a (mostly) non-recursive, quiet build system, which is not only much faster than what we had before, but more reliable too, and easier to glance through its logs, too.
• A few old settings that were never used were removed (the username() and password() settings of the mongodb() driver), some were renamed and deprecated: the replace() key transformation function of value-pairs() was renamed to replace-prefix(), as that makes the intent clearer. In this latter case, the old name is still valid, but obsoleted.
• Our integration with systemd is much tighter now: syslog-ng can notify systemd when it is ready. This also means that when systemd support is enabled, certain systemd libraries will have to be installed: syslog-ng no longer carries a convenience copy.
• A new filter was implemented: in-list, with which one can implement efficient white- or blacklists. To use it, you will need a file with one value a line, and do something along these lines:

  filter f_whitelist  
    in-list("/path/to/file.list", value("PROGRAM"));
   ;

  To do a blacklist, just negate the filter:

  filter f_blacklist  
    not in-list("/path/to/file.list", value("HOST"));
   ;

• syslog-ng now supports Linux 3.5+-style /dev/kmsg, and will use that instead of /proc/kmsg when a sufficiently recent kernel is detected (assuming one is using the system() source). The new kernel log format supports structured messages, and syslog-ng is smart enough to parse them, and make them accessible like all other message properties (with a .linux. prefix).

Like two years ago, I will be at DebConf, due in a week, and like two years ago, I will be giving a tutorial on packaging for beginners. I have a few neat things in store, which will make it worth attending, even if you happen to be past your first few packages.

Continuing my HOWTO series, in this article, I will explore how to set up syslog-ng to process JSON in various scenarios. We will touch the subject of interoperability, and have a look at multiple scenarios, in the hope that readers will find something similar to their own needs. There are many different ways in which one can plug JSON into their logging system, and it is very likely that I will not be able to cover it all within this HOWTO. However, I will explain the basics, and how to plug the pieces together, which should at least be a useful foundation to build even more complex systems onto.In essence, we will look at the following scenarios: raw JSON transport, JSON over syslog, JSON and syslog payload in the same stream. The documentation will cover both syslog-ng 3.4 and 3.5, where the 3.5 parts will be clearly marked as such. The 3.3 series do not have a JSON parser, and as such, is insufficient for most needs explored in this guide.In the default setting, the JSON parser will parse the MESSAGE part of an incoming log event, and place every key into a macro of the same name. If the incoming JSON is structured, it the keys will be converted to dot notation format: In this case, one can access the value as $ deeper.level within a syslog-ng template.The parsed keys can be prefixed using the prefix() option of the json-parser. One can also change what the parser will receive as input by using the template() option.See the documentation for more information on these.Transporting raw JSONThe simplest scenario is to take a transport like TCP, and simply push raw JSON structures through, one each line, and have syslog-ng parse that to its internal representation. One can do all kinds of things with the data then: transport it further as JSON, store it in files, in a database - the possibilities are endless, but we will explore two scenarios.JSON on TCP, using syslog field namesThe first one is receiving JSON on TCP, using syslog field names, store the parsed stuff in a file (using the conventional format), and in mongodb.

source s_tcp_json   tcp(port(10514) flags(no-parse));  ;
parser p_json   json-parser();  ;
destination d_file   file("/var/log/remote.log");  ;
destination d_mongodb   mongodb(collection("remote_log"));  ;
log  
 source(s_tcp_json);
 parser(p_json);
 destination(d_file);
 destination(d_mongodb);
 ;

This needs a bit of an explanation: we use the no-parse flag on the source, because by default, the tcp() source expects a message that conforms to the old syslog protocol. We have raw JSON, and we need to tell the source that. The other elements should be self explanatory, I believe, with the exception of json-parser(): we give it no parameters, so it will not modify the keys in the JSON it receives, keeping them intact, as-is.For this reason, incoming messages need to have the same keys as syslog-ng normally would use internally: DATE, HOST, MESSAGE, and so on, like in the following example: JSON on TCP, custom field namesA more likely scenario is when we receive JSON, but not in a layout syslog-ng uses internally. In this case, we need to rewrite the message a little, and possibly use templates, depending on what kind of output we wish to use.Lets assume the incoming JSON has these fields: As you can see, this has similar fields, but not quite, and FACILITY is missing too.In this case, we'll use a different configuration:

source s_tcp_json   tcp(port(10514) flags(no-parse));  ;
parser p_json   json-parser(prefix(".json."));  ;
destination d_file   file("/var/log/remote.log"
                          template("$ .json.timestamp  $ .json.source  $ .json.app [$ .json.id ]: $ .json.msg \n"));  ;
destination d_mongodb   mongodb(collection("remote_log")
                                value-pairs(
                                  pair("PROGRAM" "$ .json.app ")
                                  pair("HOST" "$ .json.source ")
                                  pair("PID" "$ .json.id ")
                                  pair("MESSAGE" "$ .json.msg ")
                                  pair("DATE" "$ .json.timestamp ")
                                  pair("PRIORITY" "$ .json.prio ")
                                  pair("FACILITY" "auth")
                                ));  ;
log  
 source(s_tcp_json);
 parser(p_json);
 destination(d_file);
 destination(d_mongodb);
 ;

We use the prefix() option of json-parser(), to avoid collisions with the default syslog-ng namespace. Then, we use a template for the file destination, and value-pairs() for the MongoDB one. Doing all this, we get similar results as we did in the first scenario.JSON over syslogAn even likelier scenario is when we have JSON payload in the message part of a normal syslog message. This is useful because the logs themselves remain syslog compatible, and can be transported through devices that know no better.Thankfully, if we do not tell syslog-ng that we do not want any parsing on the input, the json-parser will receive the MESSAGE part of the log, so if we have JSON payload there, things will just work:

source s_tcp_json_payload   tcp();  ;
parser p_json   json-parser();  ;
destination d_file   file("/var/log/remote.log");  ;
destination d_mongodb   mongodb(collection("remote_log"));  ;
log  
 source(s_tcp_json_payload);
 parser(p_json);
 destination(d_file);
 destination(d_mongodb);
 ;

Again, this assumes that the JSON payloads uses field names compatible with syslog-ng's defaults. Adapting it to use templates or value-pairs can of course be made, as shown in an example above.As an example, here's how a syslog message with JSON payload would look like:

<38>2013-07-22T13:45:54 localhost prg00000[1234]:  "MESSAGE": "foo", "PROGRAM": "bar" 

This would, of course, override the MESSAGE and PROGRAM fields, but the rest would be kept intact.Mixed JSON and syslog streamIn order to parse JSON that is intermingled with normal syslog streams, we can use a new feature of syslog-ng 3.4: junctions. These allow us to create branches, and tell syslog-ng something along these lines:

If there's an incoming message, that begins with @json:, parse it as JSON, otherwise treat it as a normal syslog message.

We can, of course, skip the part that mandates an in-stream marker, and things will just work, but in that case, for each JSON message, an error will get logged too, which is undesirable. Therefore, if one wants to intermingle JSON and syslog traffic on the same wire, it's best to do so with the JSON having a marker prefix. The marker, however, is not going to be part of the string the json parser receives, so setting it to an opening curly bracket will not work, unless the template is modified accordingly.The config to do this looks like this:

block parser mixed-json-parser()  
 channel  
  junction  
   channel  
    parser   json-parser(marker("@json:"));  ;
    rewrite   set-tag(".json");  ;
    flags(final);
    ;
   channel  
    flags(final);
    ;
   ;
  ;
 ;
source s_mixed  
 tcp();
 parser   mixed-json-parser();  ;
 ;

A more elaborate example can be found in a post by Bazsi.Closing thoughtsThat covers most of the use cases I saw for the JSON parser, if there are cases uncovered, or questions unanswered, I can be reached via twitter, email and a whole host of other ways, and I will happily expand this tutorial if there's enough demand for more.

Zigo posted an article earlier, one which I disagree with strongly. First of all, something that has been in use ever since git was invented is hardly a new fashion. Something that is used by the very same person who invented git and by git itself, is hardly surprising to be found so widespread. Especially not when it is used as an example in git's very own documentation! Writing it off as something silly, because of the way GitHub works, without even trying to understand the reason behind it is just plain wrong. Just because GitHub names tarballs the way it does, does not mean that we should change the way we tag.For example, cgit (used by, among others, kernel.org), uses the tag name as-is for its tarballs, unlike GitHub which prepends the project name, so one will have to mangle the filename in a debian/watch file anyway, when downloading from a host that is not GitHub, therefore his arguments for a raw version-only tag are bogus, unless your upstream is using GitHub.But I do not want to criticise only, rather, to provide a reason why a prefix is used, and why I chose the "worst" prefix: the project name itself.One very strong reason to use a prefix, either v or any other prefix is to ease tab completion. If you have a tag that is a bare number, you type the first, press tab, and get a mixture of commits and tags. You can't easily tell your completion system that you want commits or tags. With a prefix outside of the hex range, which v is, you can do that, and that makes working with it a lot easier.Is it for convenience? Yes. But ask yourself this: how many times do you have to write a debian/watch file? Once per package. How much time do you spend looking for a tag, or a commit? A lot more. So which one is most important? The convenience of someone who has to work around the tarball naming of the hosting service once, or the developer who works with the software daily? Obviously the latter!But that is not all. I'm an advocate of prefixing the tag with the project name, actually, and I've been doing that for all new projects for a while now, and I'm not going to change that, because it serves a very practical purpose: if you have a parent repository, with a lot of submodules, if git tag tells you the project name too, that makes it much easier to navigate. I don't have to bake submodule support into my shell prompt (that would be costy), and I won't find it surprising that if I enter a subdirectory, git tag fails to list the version I know I'm working on. Just because I happened to end up in a submodule, which is something I end up doing often, as I have many repositories that have submodules, which in turn have other submodules, and so on and so forth through many layers.A raw version number as a tag name is insufficient for my needs, simple as that. And I, as upstream, don't care that whoever packages my thing, will have to add a line to a watch file. That only needs to be done once, while I work with tags and commits daily.I'm sorry, but calling this naming convention a disease just because GitHub's tarball naming is what it is, without even considering that there may be other reasons behind it than legacy, and that there are hosting sites outside of GitHub, is a mistake. Dear package maintainers, please do not annoy us upstreams with requests to cripple our daily work. Thank you.

Half a lifetime ago, somewhere at the end of the last millennia I became a free software enthusiast. On and off, I've been working on Free Software for the past fifteen years - most of them unknown, discontinued by now; a huge part of this work was a hobby: small, infrequent contributions. But it was, and still is, something I enjoy doing, something that satisfies my hunger for knowledge, my desire to give back to the community I received so much from. Over the years, what originally started as a desire became a need. What started as a preference, became a requirement. And all through these years, I had a dream, a clear goal I wanted to achieve, which gave purpose to a lot of things I wrote and worked on.This past Monday, the goal was reached. I left the BalaBit support department this week, and went for greener pastures, to do what I wanted to do since I became a free software fanatic: work on free software for a living. As of July first, I'm officially a syslog-ng OSE developer, working full time on 100% Free Software. And not just any software, but something used by millions all over the world. For the first time in my life, I am able to do what I want, for a living.So how did I end up here?It all started on a boring night in December, 2010, when I wrote the first version of the mongodb destination, which also marks my entrance into the syslog-ng contributor scene (apart from a set of bugfixes I was doing in my role as a software engineer at support). From this grew an agreement between the support and development departments (and myself, of course), that I can spend 20% of my time working on syslog-ng OSE. For a while, I spent my Fridays doing just that, eventually obtaining another hat: maintaining the 3.3 stable branch, and later the 3.4 branch too. Meanwhile, the 20% percent was reconsidered, and became 50%, with the premise that it will become 100% in the not too distant future. That future is now.That future is now, and while there will be a slower ramp-up time, there are great things in store, of which, I'll talk about in a later post. Needless to say, though, even if I achieved a dream, there are other desires to pursue, and I'm not going to spend fifteen years achieving them: it's time to fire up the rocket boots, and see where they take me.Two years. Watch this place.

We have asked Moray Allan, one of the three candidates for DPL elections 2013, to tell our readers about himself and his ideas for the Debian Project. You can also read the interviews to the other two candidates: Lucas Nussbaum and Gergely Nagy.

---

Please tell us a little about yourself. I'm Moray Allan, from Edinburgh in Scotland. I'm 32. After working in academic research for a few years, I'm now working freelance on a wide mixture of topics, with recent projects in Indonesia, Romania and Kuwait. When I'm not working, I'm likely to be found walking through a city or the countryside, or otherwise relaxing at home reading a novel in French or Spanish. What do you do in Debian and how did you started contributing? In recent years, most of my Debian time was taken up organising the annual Debian conferences. But I still have a load of packages, mostly connected to an upstream Linux-on-handheld-computers project I was working on before I joined Debian to create packages for it. Why did you decide to run as DPL? I've been involved in Debian for about 10 years now, including working for the last few years in DebConf in a way similar to how the DPL acts within overall Debian. Previously I'd ruled out running due to lack of time, but currently I'm in a more flexible work situation. It seems the right time to put myself forward, and see if the ideas in my platform interest project members. Three keywords to summarise your platform. Transparency, communication, openness. (Three ways I'd like us to think about teams in Debian.) What are the biggest challenges that you envision for Debian in the future? I think the biggest challenges are for free software in general.
End-users are moving to more closed hardware -- will our software be able to run on the phones and tablets people are shifting towards? At the same time, end-users and server users are moving to "the cloud", and often depending more heavily on non-free infrastructure outside their own control. What are, in your opinion, the areas of the project more in need of technical and/or social improvements? In my platform I give a few ideas about teams and delegations, coordination and mediation, and both internal and external communication, including more organised fundraising. These are areas where I think relatively simple changes can give big benefits. Why should people vote for you? I have proven leadership experience within Debian, as I've been working on coordination and mediation tasks for some years already. At the same time, I do regular packaging work, and work in other parts of Debian like the press and publicity teams, so I'm in touch with the experience of normal Debian contributors. People should vote for me if they support my platform, which is about coordination-level changes that I would have no mandate or authority to push through unless I am elected. Name three tools you couldn't stay without. APT, emacs, ssh. What keep you motivated to work in Debian? I've used Debian on all my computers for a long time, and by now working on the distribution myself feels a natural part of that.
Fortunately I'm constantly positively surprised by Debian and by the Debian community. Are there any other fields where you call yourself a geek, besides computers? Certainly history (such as the eastern Mediterranean region in late antiquity), languages (including dead ones) and music (especially Josquin to Monteverdi).

We have asked Lucas Nussbaum, one of the three candidates for DPL elections 2013, to tell our readers about himself and his ideas for the Debian Project. You can also read the interviews to the other two candidates: Gergely Nagy and Moray Allan.

---

Please tell us a little about yourself. Hi! I'm a 31 years old french computer geek. In my day job, I'm an assistant professor (Ma tre de Conf rences) of Computer Science at Universit de Lorraine. What do you do in Debian and how did you started contributing? Like many, I started contributing to Debian by creating and maintaining packages for my own software, in the Ruby team. Then, I discovered that, even if it's not so obvious from the outside, there are a lot of areas in Debian that could use more contributors. So I just started to contribute to more and more things. There's a list of things I did in Debian in my platform. What I have been doing recently is:

• rebuild all packages in Debian on a regular basis in order to identify packages that can no longer be built, and file bugs accordingly. In order to do that efficiently, I use cluster and cloud resources (more info)
• develop and maintain Ultimate Debian Database, a data aggregator that collects data in most Debian services so that it is possible to expose it in interesting ways (e.g. find release-critical bugs affecting popular packages).
• write and maintain a Debian Packaging tutorial, (packaging-tutorial package), to provide an easy-to-read introduction to packaging in Debian.

Why did you decide to run as DPL? Two main reasons:

• Most of my Debian contributions aim at addressing problems at the distribution scale (cross-distro collaboration, Quality Assurance, data-mining). Being DPL is a great way to contribute to Debian at this level.
• the DPL campaign is a great time in Debian where we discuss the project's problems, politics and visions. Being a candidate is in itself a way to contribute to Debian (though it would be better if we had those discussions outside DPL campaigns too).

Three keywords to summarise your platform. (re-)make Debian the center of the Free Software ecosystem; foster innovation inside Debian; reduce barriers to contributions What are the biggest challenges that you envision for Debian in the future? I often have the impression that the project is losing momentum, positive energy, and slowing down. It feels like we are living on the benefits of the past. A lot of very cool things happen in the Debian ecosystem, but very often outside the Debian project (in derivative distributions). Debian should aim at reinforcing its position in the center of the Free Software ecosystem: it should be the main active intermediary between upstream projects and final users. To achieve that, we need to reinforce the visibility and the impact of Debian. This is extremely important because the values we fight for as a project are often neglected by our derivatives. What are, in your opinion, the areas of the project more in need of technical and/or social improvements? Fostering innovation inside Debian: we should be more welcoming towards innovation and experiments inside the project. Often, we merely tolerate them, and bureaucracy makes them hard and slow to conduct. As a result, people tends to innovate outside the Debian project. Making it easier to contribute to Debian: we compete with more and more projects to attract contributors. While we are already quite good at welcoming new contributors with good documentation and mentoring (much better than people usually think), there's still a lot of room for improvement. Why should people vote for you? A great thing in Debian's voting system is that you don't vote "for" or "against" a specific candidate. Instead, due to our use of the Condorcet method, you rank candidates (and also indicate those who you consider suitable for the role by ranking a virtual "None of the above" candidate). Why am I a good candidate? My previous contributions to Debian show that I have a pretty good understanding of the inner workings of the project, and that I have a track record of managing projects successfully inside Debian. I think that those are two required qualities for a DPL. Name three tools you couldn't stay without. vim, mutt, ssh. What keep you motivated to work in Debian? Debian is a fantastic project from a technical point of view (focus on technical excellence, lots of interesting challenges), but also from a social point of view: the Debian community is a great community where I have lots of good friends. Also, what's great when you contribute to Debian is that your work has a real impact, and that you see people using stuff you worked on everywhere. Are there any other fields where you call yourself a geek, besides computers? I'm not sure this really qualifies as "besides computers", but I've gotten very interested in the OpenStreetMap project lately. I very much enjoy exploring unmapped areas on a mountain bike. It feels like being Christopher Columbus or Marco Polo, but 20 minutes from home. ;) The OpenStreetMap and Debian projects also share many values, such as a great attention to quality and details.

We have asked Gergely Nagy, one of the three candidates for DPL elections 2013, to tell our readers about himself and his ideas for the Debian Project. You can also read the interviews to the other two candidates: Lucas Nussbaum and Moray Allan.

---

Please tell us a little about yourself. I was born in Hungary, a little bit over three decades ago, as a son of a biochemist and a pharmacist, who gave me the name Gergely Nagy (however, online - and offline too by now - I'm mostly known by my nickname, algernon). I went on to study human arts (hungarian grammar & literature, in particular), and to support this passion, I work as a software engineer, one who gets paid to work on free software. As such, I'm in a fortunate situation where my hobby supports my passion, and my hobby aligns well with my Debian work too. What do you do in Debian and how did you started contributing? At the moment, apart from maintaining a few packages, I'm doing a few other, mostly invisible things, like reassigning misfiled bugs so they don't end up being forgotten; or review newly uploaded packages before they enter the archive, making sure we are allowed to distribute them, and that their quality is up to our standards. I used to do quite a lot of other things, but I chose to spend the past year mostly invisible, learning. I started contributing by packaging an editor I was using at the time, but quickly ended up adopting another package - things escalated from there quickly. Why did you decide to run as DPL? There were two reasons that motivated me to run: one is that I believe I can bring something new to the table, that I can help Debian expand in new directions. The other reason is that I'm always on the lookout for new ways to contribute back to Debian, and being the project leader is a position where I believe I could contribute most at this point in time. Three keywords to summarise your platform. Non-technical contributors. What are the biggest challenges that you envision for Debian in the future? The biggest challenge is growing up, to become more than a group of computer geeks creating an amazing distribution. To become a community of a wide variety of people, where both computer geeks and art geeks feel equally at home. Yet, at the same time, where we as a project, keep our focus straight, and be the champions of Free Software. We just need to realize that there's much more to Free Software than the software itself. What are, in your opinion, the areas of the project more in need of technical and/or social improvements? I believe that while we do have many areas where we could use technical improvements, we are reasonably safe there, because we do have very skilled technical people to help us solve these problems. We can make our tools better, we can develop our infrastructure better to aid us even more - and so on and so forth. While we need work on many areas, we're on the right track there. However, when it comes to social issues, we're at a loss. We have serious trouble keeping certain topics civilised on mailing lists, we have trouble attracting women, and we have trouble reaching people who are not naturally exposed to Debian (or Free Software). We could really use a more diverse community, but that requires us to overcome quite a lot of social roadblocks, so to say. Outreach is one particular area where we need much more technical and social improvements. Why should people vote for you? People should vote me, because they found my platform, my answers on debian-vote@, and my ideas and goals convincing and worthy to pursue. People should vote me, because they trust I'll be able to serve the project well. Name three tools you couldn't stay without. Emacs, git and a pencil. Because with these three, I can pretty much do anything. What keep you motivated to work in Debian? The community. Over the years, I had the good fortune to meet with a lot of people I hold in high esteem, whose enthusiasm and motivation I found inspiring. For any other common goals Debian and I may share, in the end, it is the people within Debian that keep me motivated. Are there any other fields where you call yourself a geek, besides computers? I'm not quite there yet, but I'm working hard on becoming a human arts geek, or at least a geek of the hungarian language.

It is customary during Debian Project Leader elections to write a rebuttal of the other candidate's platform. However, this is very hard to do this year, as there are a lot of overlaps between platforms, goals and ideas this time around. It is hard to rebute another platform, without also rebuting one's own. So instead of trying to highlight where I disagree (there's very little of that, if at all), I'd like to point out where I found each platform lacking.Mind you, these notes are primarily based off of the platforms, because I'm sadly still behind on my debian-vote@ reading list. Furthermore, due to the high level of similarity between platforms, I will not always single out one or the other, but mention what I found lacking, or troublesome in general instead. So unless stated otherwise, my thoughts below apply to both Moray's and Lucas' platforms.The thing I miss most from both platforms is the curious lack of plans about non-packaging project members (something which I strongly emphasize in my own platform). Similarly, even though Moray does mention encouraging more local events, I find those few paragraphs a little bit lacking; and Lucas does not even mention local teams in his platform, even though they are a very, very important part of the wider Debian community, and a terrific tool in our asset. They can further our reach by long miles! Considering their importance, little's said about either local teams or local events, even when the candidate does explicitly recognise their importance.On the other hand, Lucas writes about innovation within Debian (which I found lacking in Moray's platform) - but while he does bring up the topic, I sadly found that section of his platform vague, a mistake I made last year myself, and which I tried to avoid this time, by explicitly listing a few of my ideas on how I'd imagine inspiring & motivating people (which, in turn, would foster innovation within the project).From what I see - and I may be wrong here, and I am obviously biased - both platforms are reasonably explicit when it comes to easier topics, things that we know to work, and which we'd all continue doing in the very same spirit as our predecessor. But when it comes to experimenting, to new ideas, I found both platforms too vague. There are exceptions, of course, Moray's intern idea for example is sufficiently well explained, as far as it is possible within the limits of a platform. I found no similar thing in Lucas' platform, however, most of the ideas he explained were technical things, and those are the areas where we're fairly good at, where we already have a reasonably chance of improving - and thus, an easier topic. I was suprised by Lucas' platform, because even though he lists the need for experimentation important, the lack of truly experimental ideas was lacking - I found more in Moray's platform.All in all, I found the discussions on debian-vote@ much more useful so far, than the platforms, a lot of things were asked and answered there that the platforms did not touch.

After one week of campaign on -vote@, many subjects have been mentioned already. I m trying here to list the concrete, actionable ideas I found interesting (does not necessarily mean that I agree with all of them) and that may be worth further discussion at a less busy time. There s obviously some amount of subjectivity in such a list, and I m also slightly biased ;) . Feel free to point to missing ideas or references (when an idea appeared in several emails, I ve generally tried to use the first reference). On the campaign itself, and having general discussions inside Debian:

• have those discussions on a more regular basis, outside DPL elections (from lucas)
• use polls to measure consensus (from lucas, question from mjr)
• use a pre-arranged questionnaire that DPL candidates would fill in (from algernon)

On getting new users and contributors to Debian:

• discussion on the various steps: Debian user first contribution regular contributor DM/DD (from lucas)
• maintain a single list of paths in (from moray and lucas)
• have some neutral people to ask about tasks, and to get suggestions from in response to explaining their current skills and experience (e.g. http://www.debian.org/women/mentoring) (from moray)
• more local meetings, compile list of regional contacts (moray)
• increase Debian presence at local meetings. Advertise the Debian Events initiative that facilitates that (from lucas)
• provide Debian ambassador title for students, similar to what is done by Google or Microsoft (from moray)
• re-work on advertising gift tags (bugs suitable for new contributors) (from lucas)
• make sure teams have list of easy tasks in their wiki pages (from lucas)
• discussion on student projects involving Debian (from lucas)
• do mentoring inside teams, like DebianMed s MoM (from moray)
• participate in other internship-like programs, like Outreach Program for Women (link from lucas), or organize our own, which would also avoid some restrictions from GSoC (northern hemisphere only (point made by moray), restricted to students (ana))
• extend internship-like programs to other kinds of work (packaging, documentation, etc.)
• localize -mentors@ (mailing lists + IRC channels for DE, FR, ES contributors) (from lucas)
• organize IRC schools/seminars about e.g. packaging (from lucas)
• introduce more gamification in mentoring (from rra)

Infrastructure, processes, releases:

• improve infrastructure to help with team maintenance (e.g. PET) (from lucas)
• authorize NMUs for archive-wide changeovers such as /usr/doc -> /usr/share/doc (from moray)
• increase visibility of RC bugs squashers by listing them in Debian Project News (from lucas)
• provide inexpensive non-monetary gifts (free t-shirts?) to RC bug squashers (from lucas)
• re-open discussion on gradual freezes (from lucas), focus attention on more important packages by improving tools (from lucas) and removing packages earlier (from moray and lucas)
• involve upstreams and downstreams in RC bug fixing (from algernon)

Relationships with upstreams/downstreams:

• use Debian money to sponsor maintainers to attend upstream events (from lucas)

This list could be moved to wiki.d.o if others find sufficiently useful to help maintaining it.

So we are at the beginning of this year's Debian Project Leader elections. And yes, after Stefano's long and (IMO) very successful DPL term, I feel as my voting machinery is somewhat stuck; it will not be so easy to get it back up to speed. Anyway, I have glanced over the three platforms, but only actually read 1.5 from the three DPL platforms. I know that whoever succeeds, I will be quite happy with the results. This year there are three runners for the post. I have worked in several teams with two of them, and would love to know better the third. In the same order as presented in the vote:

Gergely Nagy

I have not yet worked with Gergely, but enjoy reading him. The closest I have been to working with him was sketching a packaging tutorial during DebConf11, in Bosnia. Sadly, I was quite busy, and he picked up the complete workload And correspondingly, got the credits. I can say that Gergely has a very important quality, the ability to put in seductively easy words the most complex processes. So, yes, being the Debian Leader post a public-facing one, I am certain he has one of the important qualities.

Moray Allan

We have worked together organizing DebConf for many years, first loosely as orga-team members, and starting two years ago (and together with Holger Levsen) as formal delegates. I think our team is quite well balanced, and Moray plays an important role. Holger and I are sometimes anxious to take measures, measures that IMO would have proven disastrous more than once. Moray is often the voice of reason. Given that another one of the DPL's roles is to mediate in social conflicts and keep Debian working smoothly (or something close to it ;-) ), that is also a very important trait of a DPL, and I'm also sure Moray would shine as a good leader.

Lucas Nussbaum

I have long been part of the pkg-ruby-extras team (although I am way less active than what I used to, where Lucas often dazzles us with his intense streaks of activity. Among this group of three, I see Lucas firstly as the most technically oriented, the biggest implementer. Also, as the proactive bug-finder and team-herder. And yes, Lucas is maybe the most enthusiastic about the (always) important Making Debian Sexy point. So, if elected, I'm sure this facet will also make him shine

So, it's not that I'm trying to bribe our next DPL with sweet nice words about how interesting a person or how good a friend he is, but am trying to look at the election process as something different. It seems for me that we are going to choose which Debian do we want to pursue for this starting period. Now, for our soon-to-be-ex-DPL Stefano: As many will surely tell you (or already have): You rock. I truly enjoyed your DPL term, and there is much we should adopt and learn from your personality and leadership. And, although it has waned over the past few years, many people tend to publish their (stated?) vote during the campaigning period. I (think I) have never done so, and this time I will surely not do so. Choosing a DPL involves personal feelings, sympathies, and many non-objective things. And although I know nobody will feel hurt if I don't put them in the first place, I prefer not to expose such issues. I can only assure you that this year, "None of the above" will sink to the bottom of my ballot.

Last year, I invited you all to walk the plank with me, to follow me on a road, a road that even I was unsure where it led. I had a vision, I had ideas, but I had little to show for a plan. Even worse, some of my ideas, some of the things I've thought I knew, turned out to be wrong this past year. While my original plan was to pursue the goals I set out in my previous platform, I did none of that, and before I get to the meat of the platform, I owe you an explanation why: After walking the plank last year, I spent some time swimming to the shore, determined that no matter what, I will get things done. But how shall I do that? And when, with whom? Those questions needed an answer, therefore I took on a coat of an ordinary hacker, and started a journey to find the answers.That is how the past year's been spent: looking and learning. I was - and still am - following every major Debian list, I'm on IRC, absorbing all the information that fits into my tiny mind. I see now, that there's a lot more to be done than I thought last year, that some of the assumptions I made then, were wrong. And having spent a long time learning, it is my hope, that I did learn, and that this time, the plans I came up with will serve the same goal I had last year, better.That goal is as simple as growing Debian from a community of mostly technical folk to something much bigger, a community of enthusiastic, bright-eyed people who all want to do their part of making the world a better place. Big words, big task.The problemOne of the most fundamental problems with the project is that it is old, and hasn't grown up yet. We're still very focused on technical merit - don't get me wrong, that is important too, but there's much more we can do than that! We have tremendous amounts of talent, but pretty much every team is suffering from lack of people, and we seem to be slow and ineffective in recruiting new contributors (either from within the project, or outside of it), and even worse at keeping them motivated. This is not new, I worried about it last year, and I'm not the only one to see things this way, respectable members of the project expressed their pessimism publicly too.This is our biggest issue. We can be excellent at the technical level, but not being able to keep people motivated, failing to find new contributors is hurting us more and more, and it is my firm belief that without quick improvement in these areas, it won't be just me virtually walking the plank.On the flip side, we have every tool in our possession to steer ourselves into a better, brighter direction. We have excellent hackers, we have people who are terrific at communication, we have people who inspire others (just see the pattern on the dpl-game!), we have everything we need. Read on then, dear reader, and see my plan!Dancing on a tightropeTo tread on a path we have not taken so consciously before, we need to have a vision to strive for. A vision for the project as a whole, and a vision for ourselves, to see where we'd like to be a few years from now.As Stefano put it so well in his platform last year, Debian is a very unique member of the larger Free Software ecosystem - go and read his description, it can hardly be written better. This is the same vision I share, where Debian grows up to be much more than hundreds of talented people putting together a distribution. I want to see Debian becoming more than that, something that attracts not only the technical geniuses, but those who wield the power of speech and inspiration too, for these traits rarely go together.I envision a project, where people recognise each other's strengths, and make use of these strengths; where we can - and will - turn to each other, and work closely together, to achieve such good balance of skills of all kinds, as we already achieved in creating and maintaining the distribution itself.Let's dance!But alas, a vision is useless without a plan. That is a mistake I made last year, one that I will not repeat again. The approaches I choose may seem strange, or weird at first, but rest assured, they were carefully considered, and most of them tried out in a smaller setting. CommunicationWhat I've seen and experienced over the past year (and thinking back, far more than that - I just didn't know where to put the experience at that time) is that written communication is rarely the best medium to reach out to people. In this age we live in, written text reaches those who were already curious, it rarely reaches those who're still waiting for enlightenment. And even if it does, more often than not, there is no direct channel between the writer and the reader, which hurts not only the latency of the communication, but the quality too. Not to mention, that - however sad it may sound - the recipient is often too shy to engage.What does help, is face to face time. Events, where we can reach out to people, and receive immediate feedback, where we can notice the shy ones, and help them. Where we can immediately adapt to expectations.For this reason, I feel it necessary to encourage and help local teams in every possible way, to organise hackfests, code retreats, and all kinds of events that they feel will attract the bright-eyed youth (be them 20 or 80, it's the spirit that counts) we so direly need. These events need not be technical at all: a session about Debian publicity, about representing the project in press or on conferences is just as useful (if not more). Along with hackfests, we could - and should - have events focused on improving communication, for that is just as important.With strong focus placed on non-technical matters, I believe we can step on a path of rapid progress: my experience shows that techies and non-techies can inspire one another very well, much more than two techies would. With a focus on areas we are lacking in, we are indirectly improving those we are already good at. Inspiration & motivationBut finding new contributors, be them technically-sawwy or not is only part of the task, and the easier one too. It is much harder to keep people interested and motivated over a long period of time, than to find them once.On one hand, I would like to rely on those members of our community, who we all hold in high esteem (including, but not limited to those mentioned during the dpl-game). They know what keeps them going, they know what drives them away, we need to learn from that. I'd like to hear them speak more often, on conferences, if possible, as they are, I believe, a much more credible source than any elected official, at least in some situations.I'd also like to hear everyone's voice, from old members to the newest ones, I'd like to read - and if so need be, conduct - interviews with people who recently became Debian Developers, to hear about their experience, to learn what they think is good or bad, because a fresh view is just as important as a decade long experience.On the other hand, we need to act on the issues discovered too. We already know that quite a lot of trouble stems from lack of time, overburden and eventually burn out. We know the solution to this: recruit more people, and utilise the resources we do have better. Part of that can be solved by expanding our numbers, but for the other part, we may need deeper changes. What those may be, I cannot tell yet, there simply wasn't enough time to dig deeper, and I'm likely not the best person to undertake the task, either. I am, however, confident that we'll discover the solution as we travel along.The first step is gaining knowledge, without this, no further plans can be made. RecruitmentI already touched the recruitment part earlier, at least the how of the approach. What I'd like to expand on is the why, in particular: why encourage recruiting non-packaging contributors, when we are building a distribution, and we're lacking packaging manpower too?Let me answer those questions separately.First of all, I still like to think - but perhaps I am wrong - that we have an unbelievable amount of packaging manpower, which we fail to use to its full extent. We can use more, we always will be able to. But it also helps if we manage to put our existing resources to better use.And that is where non-packaging contributions come in. If we improve our skills in areas we're lacking in, that in turn, will improve the general quality of the project, which in turns improves morale, and a vibrant, well functioning, welcoming community attracts even more people, and keeps us motivated in the long run too.Mouse on the tightropeWith all that out, you may be wondering who I may be, and why you have not seen my name over the mailing lists in recent years. I'm not a terribly vocal person anymore, not a hot-headed teen I used to be some ten years ago. Most who know me, know me by my online nick name, algernon, and in most cases, I prefer that in real life too, for silly reasons I'd rather not dive into (but the primary one being that people have a hard time correctly pronouncing my name, and I have a hard time recognising my name unless pronounced the way I learnt it). Nevertheless, my name is Gergely Nagy, and I'm a recovering hacker, who intends to become a bachelor of (hungarian) arts, by majoring in Hungarian grammar & literature sometime in the next three to five years.Over the course of the past year, I also strived to observe and learn from exceptional leaders at my day job, because there, I have the advantage of meeting with them face to face, to interact with them on a daily basis. Fortunately for me, there are people among them from whom I learned a great deal about not only motivation, but about behind-the-scenes politics too - both a valuable lesson.And while I still have a tremendous amount of things to learn, I like to believe that I can do that. I know I can learn technical things extremely quickly (my day job depends on that, I would be out of a job if I failed at that), I'm positive that I can do the same in other areas as well, at least as long as it doesn't involve extreme amounts of economics. That proved to be a major barrier in the past.But back to the more important point: my organising, presentation and leading skills. I'm a co-organiser of the Budapest Clojure User Group meetups, I started to encourage GSoC participation at my day job last year (we participated thanks to OpenSUSE who gave us a slot), and I'm driving it this year, aiming to become a mentoring organisation of our own. I'm doing regular talks and presentations, participate in code retreats, meetups and other similar events where I can both practice and learn the art of interacting with people, and the fine art of organising events.

Last year, I invited you all to walk the plank with me, to follow me on a road, a road that even I was unsure where it led. I had a vision, I had ideas, but I had little to show for a plan. Even worse, some of my ideas, some of the things I've thought I knew, turned out to be wrong this past year. While my original plan was to pursue the goals I set out in my previous platform, I did none of that, and before I get to the meat of the platform, I owe you an explanation why: After walking the plank last year, I spent some time swimming to the shore, determined that no matter what, I will get things done. But how shall I do that? And when, with whom? Those questions needed an answer, therefore I took on a coat of an ordinary hacker, and started a journey to find the answers.That is how the past year's been spent: looking and learning. I was - and still am - following every major Debian list, I'm on IRC, absorbing all the information that fits into my tiny mind. I see now, that there's a lot more to be done than I thought last year, that some of the assumptions I made then, were wrong. And having spent a long time learning, it is my hope, that I did learn, and that this time, the plans I came up with will serve the same goal I had last year, better.That goal is as simple as growing Debian from a community of mostly technical folk to something much bigger, a community of enthusiastic, bright-eyed people who all want to do their part of making the world a better place. Big words, big task.The problemOne of the most fundamental problems with the project is that it is old, and hasn't grown up yet. We're still very focused on technical merit - don't get me wrong, that is important too, but there's much more we can do than that! We have tremendous amounts of talent, but pretty much every team is suffering from lack of people, and we seem to be slow and ineffective in recruiting new contributors (either from within the project, or outside of it), and even worse at keeping them motivated. This is not new, I worried about it last year, and I'm not the only one to see things this way, respectable members of the project expressed their pessimism publicly too.This is our biggest issue. We can be excellent at the technical level, but not being able to keep people motivated, failing to find new contributors is hurting us more and more, and it is my firm belief that without quick improvement in these areas, it won't be just me virtually walking the plank.On the flip side, we have every tool in our possession to steer ourselves into a better, brighter direction. We have excellent hackers, we have people who are terrific at communication, we have people who inspire others (just see the pattern on the dpl-game!), we have everything we need. Read on then, dear reader, and see my plan!Dancing on a tightropeTo tread on a path we have not taken so consciously before, we need to have a vision to strive for. A vision for the project as a whole, and a vision for ourselves, to see where we'd like to be a few years from now.As Stefano put it so well in his platform last year, Debian is a very unique member of the larger Free Software ecosystem - go and read his description, it can hardly be written better. This is the same vision I share, where Debian grows up to be much more than hundreds of talented people putting together a distribution. I want to see Debian becoming more than that, something that attracts not only the technical geniuses, but those who wield the power of speech and inspiration too, for these traits rarely go together.I envision a project, where people recognise each other's strengths, and make use of these strengths; where we can - and will - turn to each other, and work closely together, to achieve such good balance of skills of all kinds, as we already achieved in creating and maintaining the distribution itself.Let's dance!But alas, a vision is useless without a plan. That is a mistake I made last year, one that I will not repeat again. The approaches I choose may seem strange, or weird at first, but rest assured, they were carefully considered, and most of them tried out in a smaller setting. CommunicationWhat I've seen and experienced over the past year (and thinking back, far more than that - I just didn't know where to put the experience at that time) is that written communication is rarely the best medium to reach out to people. In this age we live in, written text reaches those who were already curious, it rarely reaches those who're still waiting for enlightenment. And even if it does, more often than not, there is no direct channel between the writer and the reader, which hurts not only the latency of the communication, but the quality too. Not to mention, that - however sad it may sound - the recipient is often too shy to engage.What does help, is face to face time. Events, where we can reach out to people, and receive immediate feedback, where we can notice the shy ones, and help them. Where we can immediately adapt to expectations.For this reason, I feel it necessary to encourage and help local teams in every possible way, to organise hackfests, code retreats, and all kinds of events that they feel will attract the bright-eyed youth (be them 20 or 80, it's the spirit that counts) we so direly need. These events need not be technical at all: a session about Debian publicity, about representing the project in press or on conferences is just as useful (if not more). Along with hackfests, we could - and should - have events focused on improving communication, for that is just as important.With strong focus placed on non-technical matters, I believe we can step on a path of rapid progress: my experience shows that techies and non-techies can inspire one another very well, much more than two techies would. With a focus on areas we are lacking in, we are indirectly improving those we are already good at. Inspiration & motivationBut finding new contributors, be them technically-sawwy or not is only part of the task, and the easier one too. It is much harder to keep people interested and motivated over a long period of time, than to find them once.On one hand, I would like to rely on those members of our community, who we all hold in high esteem (including, but not limited to those mentioned during the dpl-game). They know what keeps them going, they know what drives them away, we need to learn from that. I'd like to hear them speak more often, on conferences, if possible, as they are, I believe, a much more credible source than any elected official, at least in some situations.I'd also like to hear everyone's voice, from old members to the newest ones, I'd like to read - and if so need be, conduct - interviews with people who recently became Debian Developers, to hear about their experience, to learn what they think is good or bad, because a fresh view is just as important as a decade long experience.On the other hand, we need to act on the issues discovered too. We already know that quite a lot of trouble stems from lack of time, overburden and eventually burn out. We know the solution to this: recruit more people, and utilise the resources we do have better. Part of that can be solved by expanding our numbers, but for the other part, we may need deeper changes. What those may be, I cannot tell yet, there simply wasn't enough time to dig deeper, and I'm likely not the best person to undertake the task, either. I am, however, confident that we'll discover the solution as we travel along.The first step is gaining knowledge, without this, no further plans can be made. RecruitmentI already touched the recruitment part earlier, at least the how of the approach. What I'd like to expand on is the why, in particular: why encourage recruiting non-packaging contributors, when we are building a distribution, and we're lacking packaging manpower too?Let me answer those questions separately.First of all, I still like to think - but perhaps I am wrong - that we have an unbelievable amount of packaging manpower, which we fail to use to its full extent. We can use more, we always will be able to. But it also helps if we manage to put our existing resources to better use.And that is where non-packaging contributions come in. If we improve our skills in areas we're lacking in, that in turn, will improve the general quality of the project, which in turns improves morale, and a vibrant, well functioning, welcoming community attracts even more people, and keeps us motivated in the long run too.Mouse on the tightropeWith all that out, you may be wondering who I may be, and why you have not seen my name over the mailing lists in recent years. I'm not a terribly vocal person anymore, not a hot-headed teen I used to be some ten years ago. Most who know me, know me by my online nick name, algernon, and in most cases, I prefer that in real life too, for silly reasons I'd rather not dive into (but the primary one being that people have a hard time correctly pronouncing my name, and I have a hard time recognising my name unless pronounced the way I learnt it). Nevertheless, my name is Gergely Nagy, and I'm a recovering hacker, who intends to become a bachelor of (hungarian) arts, by majoring in Hungarian grammar & literature sometime in the next three to five years.Over the course of the past year, I also strived to observe and learn from exceptional leaders at my day job, because there, I have the advantage of meeting with them face to face, to interact with them on a daily basis. Fortunately for me, there are people among them from whom I learned a great deal about not only motivation, but about behind-the-scenes politics too - both a valuable lesson.And while I still have a tremendous amount of things to learn, I like to believe that I can do that. I know I can learn technical things extremely quickly (my day job depends on that, I would be out of a job if I failed at that), I'm positive that I can do the same in other areas as well, at least as long as it doesn't involve extreme amounts of economics. That proved to be a major barrier in the past.But back to the more important point: my organising, presentation and leading skills. I'm a co-organiser of the Budapest Clojure User Group meetups, I started to encourage GSoC participation at my day job last year (we participated thanks to OpenSUSE who gave us a slot), and I'm driving it this year, aiming to become a mentoring organisation of our own. I'm doing regular talks and presentations, participate in code retreats, meetups and other similar events where I can both practice and learn the art of interacting with people, and the fine art of organising events.

In no particular order, here are my 4 picks for the DPL thunderdome:

• algernon
• gregoa
• rra
• KiBi

I hope they all run. Really.

Yeah, wait, what? No, really! I took a look through clojure-py, and found out something pretty rad. In order to get clojurepy scripts to load other clojurepy, it had to shim out and add a new importer for clojure scripts. What this really means, is that you can import Clojure from Python, which is pretty sweet. I abused the internals here, and added it to dput-ng as a quick hack. Basically, I just had to import clojure.main, and let the main function set up the sys shim. I would set it up in dput, but I d have to import that module anyway. Remember, when doing this, the namespace ((ns ...)) needs to match the filename. So, I present the first Clojure hook for dput-ng:

; Copyright (c) Paul R. Tagliamonte <paultag@debian.org>, 2012, under the
; terms of dput-ng itsself.
(ns clojtest
  (:require dput.core
            dput.exceptions))
(defn log [x]  ; for debug output
  (.debug dput.core/logger x))
(defn dput-checker [changes profile interface]
  (cond (>= (-> changes (.get "maintainer") (.find "arno@debian.org")) 0)
    (throw (dput.exceptions/HookException. "Maintainer's Arno. Aborting upload"))
  :else
    (log "Nah, it's not arno, we're good")))

This, of course, checks if the maintainer is Arno, and throws a fit if it is. Gist is over on gist.github. After, Algernon added his own checker, which throws a fit if you have a package in the B-Ds that you aught to not use (such as dpatch)

; Copyright (c) Gergely Nagy <algernon@debian.org>, 2012, under the
; terms of dput-ng itself.
(ns bd-blacklist
  (:require dput.core
            dput.exceptions
            dput.dsc))
(defn prune-build-deps
  "Prune a string representation of the build-depends so that only a
  list of packages remain."
  [bd-string]
  (map #(first (-> % (.strip) (.split " "))) (.. bd-string (split ","))))
(defn has-blacklisted?
  "Given a dsc file and a blacklist, check if any of the
  build-depencencies are in that list. Throws an error if there are
  matches."
  [dsc-file blacklist]
  (let [dsc (dput.dsc/parse_dsc_file dsc-file)
        build-deps (prune-build-deps (.. dsc (get "build-depends")))]
    (if-let [bad-bd (some blacklist build-deps)]
      (throw (dput.exceptions/HookException. (str "Blacklisted build-dependency found: " bad-bd)))
      (-> dput.core/logger (.trace "Build-Dependencies do not have anything on the blacklist")))))
(defn blacklist-checker
  "Checks whether the dsc has blacklisted build-dependencies, ignores
  the check when no dsc is to be found."
  [changes profile interface]
  (if-let [dsc-file (.. changes (get_dsc))]
    (has-blacklisted? dsc-file (set (get profile "bd-blacklist")))
    (-> dput.core/logger (.trace "No .dsc found, build-dependencies cannot be checked"))))

You can check that out in the git tree Hacks welcome!

I ve pushed up some code (named familytree) to my GitHub, which lets folks browse the social connections that make up Debian. Many thanks to the number of people who gave me feedback (arno, luca, algernon (at least!)) Y all rock! I ve taken the dump of information from nm.debian.org, and rendered it out into four datasets.

• Advocations for a person
• People who one has advocated
• If the person is a Debian Developer Emeritus
• Who a person has AMd for

Mashing this up with an example d3 page, I ve come up with what I m calling debgraph . Here are some notable examples that I think are rad :) By the way - green lines indicate sponsorship, black lines indicate sponsors, and dashed lines indicate AM-ing. Tan nodes are DD-emeritus, and blue is active. I don t think this handles MIA correctly. Anyway, here it is: Me! (paultag) Algernon tbm (OK, this one is massive, I ve scaled it down a skitch old computer warning, it ll peg your CPU!) zack

A melancholic look at intellectual disability and how it was regarded and treated by the society of the time (1960s). Despite an inevitable conclusion, it was enjoyable and thought provoking.

It seems I have been wrong about the origins of the Seville Orange joke Rather than Algernon Sidney It would appear to have been quipped by an 18th century Anglo-Irish actor named James Quin as recounted in "Lives of the Players" by John Galt (not that John Galt but this one) in 1831.

Quin once, in the character of Cato, received a blow in his face by an orange thrown from the upper gallery; such a circumstance would have disconcerted many an actor possessed of less presence of mind, but instead of being disturbed, he wiped his face, and taking it up, observed, "It was not a Seville orange."

A proto-version of the joke does date back to Sidney's time. It was made by none less than William Shakespeare in "Much Ado About Nothing" Act II, Scene 1:

DON PEDRO: Why, how now, count! wherefore are you sad?

CLAUDIO: Not sad, my lord.

DON PEDRO: How then? Sick?

CLAUDIO: Neither, my lord.

BEATRICE: The count is neither sad, nor sick, nor merry, nor well; but civil count, civil as an orange, and something of that jealous complexion.

Note Don Pedro is from Aragon which is close enough to Seville for Elizabethan comedy purposes. But while 300+ years is impressive, this joke from Sumeria c. 19th-16th centuries BC is older by far:

Something which has never occurred since time immemorial: a young woman did not fart in her husband's lap.

See The world's ten oldest jokes

My lord Somerset was attending the theatre when a ruffian did assail him with an orange. Whereupon my lord remark'd, "'Twas not a Seville orange."

-- attributed to Algernon Sidney.